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(57) ABSTRACT 

A single sign-on (SSO) mechanism to enable a given user to 
access a target application on a target resource in a distrib- 
uted computer enterprise. One or more configuration direc- 
tives each identifying a given logon process and any asso- 
ciated methods required to access the target application on 
the target resource are stored in a locally accessible database 
(CIM). For each of a set of users, a globally-accessible 
database (PKM) stores user-specific and application-specific 
information enabling the user to access and logon to one or 
more target resources. During a particular session, a logon 
coordinator (LC) mechanism coordinates given user infor- 
mation with the configuration directive to enable the given 
user to perform a given action with respect to the target 
application without specifying the given logon process and 
the application-specific information. 
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METHOD AND SYSTEM FOR SINGLE SIGN specific logon scripts. This is how many "homegrown" 

ON USING CONFIGURATION DIRECTIVES single sign-on systems work today. This technique is the 

WITH RESPECT TO TARGET TYPES least extendible design because it ties passwords (and logon 

target code) to each machine the user uses. It is also hard to 

BACKGROUND OF THE INVENTION 5 maintain passwords in this design because passwords need 

to be changed both in the applications and in the logon 

1. Technical Field scripts. For a mobile user, the scripts need to be present on 
The present invention relates generally to accessing het- a n machines the user might use. The overall security of this 

erogeneous networks and reducing costs by increasing pro- approach is thus very weak. 

ductivity for end-users and system administrators in an 10 Another target logon alternative involves building in all 

enterprise computer environment. ^ logon mclhods for every possible target to which any 

2. Description of the Related Art user may desire to logon. This "hardcoded" approach 
With sprawling client-server systems growing daily, assumes that all workstations and applications are config- 

applications and information are spread across many PC ured similarly and do not change. Because the logon meth- 

networks, mainframes and minicomputers. In a distributed 15 ods are built into the solution, changes made to the logon 

system environment connected by networks, a user must methods require changes to the actual solution itself. This 

access many database systems, network systems, operating approach is costly and also is not very extensible, 

systems and mainframe applications. To use these systems Irrespective of their design, known SSO systems such as 

and applications, the user must issue separate sign-on com- those described above require the user to have one and only 

mands for each specific system or application. Indeed, it is 20 one program to sign on to a target, and that program must be 

not unusual for a user to encounter ten or more different installed on all SSO clients. This restriction is very unde- 

login sessions during a working shift, and these often are sirable. Thus, for example, a user may have a preferred 

different interfaces with different userid and authentication program installed on his or her office system to access a 

information, usually passwords. This places the user under given application, and that same user may have -a laptop 

a significant burden to remember and maintain this infor- 25 machine that he or she uses out of the office that preferably 

mation. accesses the same application with different software. 

It would be quite beneficial to provide a single sign-on It would be desirable to provide a mechanism by which a 

(SSO) tool to enable authorized users to perform one initial given user does not have to specify a particular program on 

sign-on to access a variety of networks, systems and appli- the client when using SSO to log on to a particular target. It 

cations. A single sign-on system should provide secure is also desirable to provide a mechanism by which the SSO 

storage of user passwords, support for more than one user user does not have to specify the operating system used by 

password, as well as support for multiple target logon the client. The present invention addresses this need, 

methods. Each of these issues presents varying design ddtcc cmmmadv nt: nrc iMvcMTrnu 

considerations. BRIEF SUMMARY OF THE INVENTION 

With respect to the first issue, there are multiple A primary object of this invention is to provide "free 

approaches to storing and managing passwords. One seating" support in a single sign -on environment. Free 

approach is to use the same password for all accessible seating means that a user does not have to specify a 

systems/applications. This technique may weaken system particular program on the client, or have a particular oper- 

security, however, because a compromised password in any 4Q ating system on that client, when using SSO to log on to a 

of the systems or applications compromises the user's particular target. 

privileges on these systems and applications at the same This object is preferably achieved using a data model 

time. Further, different sign-on mechanisms may have their where information used to sign on to applications is kept in 

own distinctive password requirements and, thus, it is prob- two separate databases. One database is a global database 

lematic to use the same password for multiple targets. 45 that keeps user configuration information, and the second 

Another approach to storing and managing passwords is database is a local database that keeps local application 

password-mapping, which refers to using the user's primary specific information. 

password to encrypt all the user's secondary passwords. The More specifically, this invention provides a single sign-on 

encrypted passwords are stored in a local storage space (SSO) framework that allow users to sign on to a client 

accessible to the user (e.g., a local file, a readable/writable 50 system one time entering one password. The SSO frame - 

smartcard, and the like). Once the primary password is work then signs on to other applications on the user's behalf, 

verified, the local system authentication module obtains the The SSO framework supports storage of all passwords 

passwords for other sign-on systems and applications by and keys belonging to a user in secure storage (e.g., either 

decrypting the mechanism-specific encrypted password with in local storage, a centralized password service, a smartcard, 

the primary password. The security of this password- 55 or the like), so that the user needs to remember only one ID 

mapping scheme assumes that the primary password is the and password. Upon authentication, the SSO mechanism 

user's strongest password, and it also depends on the secu- securely retrieves all the passwords for a user from the 

rity of the local storage for the secondary passwords. If the secure storage and automatically (i.e. without additional user 

secondary passwords arc stored in an untrusted publicly intervention) issues sign-ons to each system/application the 

accessible machine, an intruder is provided with opportuni- 60 user is authorized to access. 

ties for potential attacks. Moreover, although this approach The system framework preferably includes a number of 

is simple, the password file must be moved from machine to modules including a configuration information manager 

machine by the user to logon to more than one machine. (CIM), which includes information on how to logon to the 

The target logon alternatives also influence the single applications configured on a given machine, a personal key 

sign-on system design. In particular, the method used for 65 manager (PKM), which includes information about users, 

storing a user password heavily influences the design of systems and passwords they use to logon to those systems, 

target logon code. It is known to embed passwords in target and a logon coordinator (LC), which retrieves the user's 
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passwords from PKM and uses them in conjunction with be implemented. The single sign-on (SSO) mechanism com- 

target-specific logon code to log users onto all their systems, prises both server 20 and client (runtime services) compo- 

preferably without any additional user intervention. nents 14, 16 and 18. For purposes of illustration, each of 

The CIM facilitates adding new logon methods as needed. ^ese are illustrated as a computer. It is also assumed that 

Information is preferably stored in the CIM using "tern- 5 system users log onto the domain via client machines in a 

plates" referred to a program template files (PTFs). A given knowQ manner. 

PTF thus is used to create entries in the CIM. This template ^J? 61 * ! he P 6 ™ 1 * an . d c l ient servic . es com P° neQts of 

mechanism enables an application vendor to specify how to ? e S $° ™*«u™ are implemented in a computer or 

logon to a given application. Thus, independent software « m f^L^°J e t ach . serv ^ ^ b « * NSC 

j j 4 i vv , .. . v *• • * tu m System/6000® (a reduced instruction set or so-called RISC- 

vendors and others can easily plug their applications into the io ^ worksUti v on) ^ the MX (Advanced Interactive 

SSO framework without writing a large amount of code. Executive) operating system, preferably Version 4 or greater. 

The SSO framework implements a "data model" where Alternative servers include machines running Sun Solaris V 
information used to sign on to applications is kept in the 2,5.1 or Microsoft Windows NT 4.0. 
separate PKM and CIM databases. The PKM is globally Each client machine m the domakl may be a computer 
accessible and stores user-specific information, and the CIM such ^ a desktop machine or laptop A typical client 
is locally accessible and stores application-specific informa- mach ine is an Intel x86 or Pentium®-based computer ruc- 
tion derived from PTF files. In operation, the logon coordi- ning windows > 95 or greater operating system. Alternatives 
nator (LC) accesses the PKM to obtain the user's informa- include machines mnning 0 S/2® Warp 3.x or higher, or a 
tion (e.g., which target systems and applications to which the Microsoft Windows NT workstation. Each client worksta- 
user can sign-on), as well as the passwords and keys for 20 tion typically sup ports TCP/IP and may include a network 
those systems/applications. The LC then uses these operating system (NOS). A typical client is a Novell Net- 
passwords/keys, together with the target logon information ware cliem (for Netware logons)> an os/2 LAN Server client 
found in the CIM, to sign-on to vanous target systems and ( for os/2 lan Server logons), an OS/2 Warp Server client 
applications. Sign-on is preferably based upon the target's (for OS/2 Warp Server logons), or the like. These examples, 
own protocols and mechanisms as defined in the PTF. however, are merely representative and should not be con- 
Hie foregoing has outlined some of the more pertinent strued to limit the invention in any way. 
objects of the present invention. These objects should be Many d iff eren t types of target systems/applications are 
construed to be merely illustrative of some of the more accessed using the single sign-on mechanism. These include 
prominent features and applications of the invention. Many ^ Q distributed applications, databases, printers, and other 
other beneficial results can be attained by applying the resources throughout the enterprise. Representative systems 
disclosed invention in a different manner or modifying the and applications include, without limitation: 3270 and 5250- 
invention as will be described. Accordingly, other objects based applications, IBM OS/2 Lan Server 4.x and OS/2 
and a fuller understanding of the invention may be had by warp Server, Novell Netware 3,x and 4.x, Microsoft NT 4,0 
referring to the following Detailed Description of the pre- ^ Servefj Databases (e.g., DB2, Oracle, Sybase, Informix, MS 
ferred embodiment. SQL Server), Lotus Notes 4.x, PeopleSoft applications, 
BRIEF DESCRIPTION OF THE DRAWINGS DCE applications written to conform to The Open Group 

(formerly known as the Open Software Foundation), and 

For a more complete understanding of the present inven- other applications. These examples, again, are merely rep- 

tion and the advantages thereof, reference should be made to 4Q resentative. 

the following Detailed Description taken in connection with p IG 2 illustrates the main components of the inventive 

accompanying drawings in which: single s ign_ on (SSO) mechanism of the present invention. 

FIG. 1 (is a computer enterprise environment in which the They preferably include an authentication module 21, a 

present invention may be implemented; configuration information manager (CIM) 22, a personal key 

FIG. 2 is a block diagram of the main functional compo- 45 manager (PKM) 24, and a logon coordinator (LC) 26. In 

nents of the invention single sign-on (SSO) mechanism; general, the authentication module 21 authenticates a given 

FIG. 3 is a representative single sign-on transaction user to tne remainder of the single sign-on (SSO) mecha- 

according to the present invention; nism. On systems with local operating system security, the 

FIG. 4 is a representative logon interface screen for the authentication mechanisrn 21 usually is integrated with the 

SSO transaction of FIG 3* 50 * oca ^ ^ authentication. The authentication module prefer- 

™^ _ . \ ^ TTI • 1 * * J • (U ably supports different authentication mechanisms (e.g., 

FIG. 5 is a representative GUI screen identifying the .1 . j , iL ... \ f 

/ r r ^1 secret key, smartcards, public/private key, and the like), 

systems/applications for a particular user; mi J ' . . „ . 

✓. i.ii 1 1 ■ , iL c t . The configuration information manager (CIM) 22 

FIG. 6 is a high level "^ration of the operation of the info ^ ation on how , 0 b , 0 f he a ^ plica ' tions 

logon coordinator (LC) or. the SSO mechanism; c , • , . n °, , , -zf M . 

& v ' ' 55 configured on a given machine. Preferably, a CIM is sup- 

FIG. 7 is a flowchart illustrating the LC operation; ported on each client machine from whicn tne SSO mecha- 

FIG. 8 illustrates how the logon coordinator performs a n ism is provided. A given CIM typically is not globally 

matching operation between PKM and CIM entries; accessible from other machines on the domain. Information 

FIG. 9 is a flowchart of a change password operation; and in the CIM preferably is formatted according to a program 

FIG. 10 is a block diagram of a representative multiple 60 template file (PTF) 25, as will be illustrated below in more 

SSO server implementation and a DCE Security Registry for detail. The CIM thus stores "configuration directives" iden- 

supporting the PKM data model. tifying the given logon process and the methods required to 

access a particular application on the target resource. New 

DETAILED DESCRIPTION OF THE i ogon me thods may be added using the PTF mechanism as 

PREFERRED EMBODIMENT 65 w gi be seen _ 

FIG. 1 illustrates a portion of a distributed computer The PKM 24 contains information about users, systems 

environment domain 10 in which the present invention may and passwords they use to logon to those systems. 
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Preferably, PKM 24 is a secure, globally accessible reposi- Target type— specifies what type of "application" the 

tory that facilitates the single sign-on process. Although not program is; 

meant to be limiting, with respect to a given user, the PKM Default target — indicates if an entry is the default of a 

(as will be described) preferably stores such information as given type; 

a username, a set of one or more password(s), and any other 5 Specific application information — describes interfaces 

application environment-specific information such as needed to perform operations like logon, logoff, and the 

domain name, hostname, application name, and the like. like; 

Because this access information preferably is centralized in Program Preferences — indicates timeouts and retry 

the PKM, users can access their target resources with one counts; and 

sign-on from any workstation. They can also manage their 10 Interface directory— client-specific information on how to 

passwords from this one repository, as will also be seen. locate the application interface code. 

To this end, the logon coordinator 26 functions generally The expected runtime flow of a user interacting with the 

to retrieve the user's passwords from the PKM and uses single sign-on (SSO) mechanism is illustrated in FIG. 3 and 

them in conjunction with the target specific logon code described as follows. At step 1, a user either logs in to a local 

(identifiable from the CIM entries) to log users onto all (or 15 operating system (if required by the local operating system) 

some subset of) their systems, preferably without any addi- or logs on via a logon interface (if local logon is not required 

tional user intervention. As will be described in more detail by the operating system). A representative logon interface 

below, the LC also preferably maintains state information screen is illustrated, for example, in FIG. 4. The user's local 

for a given user and application, called a "user target", to logon enables the authentication module (GSO Auth) on the 

help coordinate and execute future operations. 20 local machine (if supported) to authenticate the user (step 2) 

According to the invention, the single sign-on mechanism to the authentication service that is integrated with the 

preferably uses a "data model" where information used to password storage service. 

sign on to applications is kept in two separate databases. The A successful authentication triggers the smgle sign-on 

first database is the PKM 24, which is preferably a global graphical user interface (GUI) to display (at step 3) the 

database and is thus accessible from all client machines in a 25 systems/applications the user is able to logon to and the 

given domain. The PKM 24, as noted above, keeps user status of the logon process. A representative GUI screen 

configuration information. The second database in the CIM display is illustrated in FIG. 5. The GUI also calls the logon 

22, which is preferably a local database and is thus acces- coordinator on the local machine (at step 4) to retrieve the 

sible only from the current client machine. The CIM need user's configuration information and target configuration 

not be merely a local database, however. Each cheat 30 information. As described, the logon coordinator gets the 

machine from which the SSO support is provided runs a user's information (which target systems and applications 

CIM. Thus, multiple instances of CIM 22 are illustrated in the user can sign-on to) and the passwords and keys for those 

FIG. 2. Likewise, each client machine preferably also runs systems/applications from the personal key manager. If the 

an instance of the logon coordinator 26. personal key manager is implemented as a remote service 

Thus, for example, the PKM 24 contains user-specific 35 ( or if the necessary information is located remotely), the 

application data which includes: P ersonal ke y mana S er chent ( at ste P 5 > S ets the "formation 

m , • i *j ( - f ■ „ ««, D# » in a secure fashion (i.e. the passwords/keys are encrypted for 

Target name — uniquely identifying a user target . . . v , / . _ ' / J £ t . 

m & J . /.«,•.„.. transmission). The credentials returned from the authentica- 

Target type-specifies what type of application this tion module are ^ by ^ key manager ^ tQ 

target is, 40 ensure mal me user wn0 logged on to the mechanism is the 

Domain/Host/Application name— specifies application uger wh(J relrieves the passw0 rds. 

information, specific for this target; ^ logon coordinator ( step 6) then uses these passwords/ 

User ID— specifies user id on target; keys and the target i ogon information found in the configu- 

Key information— specifies the user's key (password) Q rat i 0 n information manager (CIM) to sign-on to various 

on the target; 45 target systems and applications, based upon the targets' own 

User preferences — specifies user specific information for protocols and mechanisms. The logon coordinator prefer- 

this target; and ably provides status information about the state of the logons 

Preferred program name — specifies a preferred PTF entry and also allows some targets to be launched asynchronously 

to use with this target. (after the initial sign-on processing has completed). 

The personal key manager 24 enables a given SSO user to 50 This mechanism allows for different passwords for dif- 

manage all the passwords the user possesses in a secure and ferent target systems and applications without requiring the 

effective manner. According to the invention, each user to remember all such passwords. The user remembers 

application, server, or system to which a user needs an only one password to log into the mechanism, which then 

ID/password pair to logon is defined as a "target". Using a performs the subsequent logging into the different system by 

GUI interface, the user creates a target in PKM correspond- 55 acquiring the secret keys from the secured key manager 

ing to each real target to which the user can logon, and the (local or remote). This SSO mechanism enhances security as 

user may create as many (or as few) targets as the capability well as ease of use. It also enables the user to access existing 

of a specific PKM implementation allows (or that the user systems without having to create or to modify existing user 

desires). Independent of any implementation, a generic definitions on those systems. As will be seen, the mechanism 

PKM application programming interface (API) preferably is 60 also allows a user to change his or her single sign-on 

used by the SSO framework to create a new target, to update password without requiring changes of the target keys/ 

a target's data, to query a target's information (with or passwords or vice versa. Target password changes can be 

without passwords), and to delete an existing target. made to one or more selected target systems. 

The second database, the CIM 22, preferably contains FIG. 6 is a high level illustration of the operation of the 

entries derived from the program template files (PTFs). This 65 logon coordinator 26. FIG. 7 is a flowchart illustrating one 

database contains application (i.e. program) specific preferred single sign-on method, which may be suitably 

information, which includes (for example): implemented in a computer program. The routine begins at 
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step 40 when a user 30 (at a workstation 32) requests a logon ating system on that client, when using the SSO mechanism 

to a given application (Target 1) 33. In response, the routine to log onto a particular target. The free seating method 

continues at step 42 with the logon coordinator 26 issuing a allows the user to install any program (appropriate for the 

query to the PKM 24 for the information regarding the user's client machine OS) on his or her client machine and then 

"key" (which, as described above, may include the 5 have the logon coordinator pick the appropriate one to logon 

username, password, and any other application to the target. The LC preferably does this by examining the 

environment-specific information as described above). At "target type" associated with the programs on the client and 

step 44, the information is returned to the logon coordinator. with the target the user is trying to access. If the program has 

Then, the routine continues at step 46 with the LC issuing a the same target type as the target, then the LC knows it can 

query to the CIM to obtain the target information. At step 48, 10 use that program to access that target. This means that the 

the target information is returned to the LC. The information user can logon to a target if any program on the system 

retrieved from the CIM 22 for the particular application matches the target type, rather than needing a fixed program 

determines how to logon to the application (e.g. what type to do the logon. 

of invocation to make, what actual invocation, and the like). For example, a user may have a target "HOST1" of type 

At step 52, the logon coordinator 26 substitutes given data 15 "3270 Emulator," On the machine on the user's desktop, the 

received from the PKM into substitution variables in the user may have the "telnet3270" program, which is of the 

invocation strings returned from the CIM. In particular, the type "3270 Emulator" available to logon to HOST1. On the 

logon coordinator performs a matching operation; for each user's laptop, the user may have the IBM Personal Com- 

PKM target entry, the coordinator determines whether there municator program available, which is also a 3270 Emulator, 

is a corresponding CIM entry. If so, step 52 binds the two 20 to logon to that target. When the user uses the SSO mecha- 

entries together. This is illustrated in FIG. 8. At step 54, the nism on the desktop machine, the LC will use telnet3270 as 

logon coordinator 26 invokes the logon method(s) defined the 3270 Emulator to logon to HOST1; on the laptop, IBM 

by and stored in the CIM. This completes the processing. Personal Communicator will be used. These examples, of 

Generalizing, the logon coordinator (LC) thus takes the course, are merely representative of the inventive free seat- 

data from the personal key manager (PKM) and the direc- 25 ing support concept. 

tives in the PTF and interprets the data, together with current The generic PKM data model described above may be 

state information, to perform a given action. Such action is implemented in many ways including, without limitation, 

carried out with respect to the users 'systems and applica- DCE client/server, a real smartcard, a soft (disk-based) 

tions and includes, for example, a logon operation, a change virtual smartcard, or the like. One advantage of using an 

password operation, or a logoff operation. 30 implementation-independent PKM API as described herein 

If the user requests a change password operation, the LC is that different mechanisms may be pluggable without any 
makes the correct invocation to change the password and modification to other SSO application programs. Moreover, 
coordinates the password update in the PKM. Continuing multiple mechanisms can be configured on one machine and 
with the above-described example (involving Target 1) a a user has the option to choose a specific one. 
representative flowchart of this function is illustrated in FIG. 35 A representative PKM is implemented in a known DCE 
9. By way of brief background, the logon coordinator Security Registry architecture conforming to The Open 
preferably maintains state information for a given user and Group DCE Standard. Familiarity with DCE security 
application, a "user target", to help coordinate and execute mechanisms is presumed in the following discussion, 
future operations. By looking at the current state of a user FIG. 10 illustrates the basic PKM architecture, which may 
target and interpreting data in the PKM entry and the PTF, 40 be distributed across multiple machines in the domain. In 
the LC can determine which operations are required to particular, it is first assumed that multiple SSO servers 
satisfy an SSO request. For example, the PTF can specify lQOa-n are configured and running in the domain. Multiple 
that a user should be logged on to an application before PKM servers are replicated on different machines, e.g., for 
performing a change password operation. Therefore, the LC performance and scalability. Each server preferably per- 
would keep track of the logon state of a user target to 45 forms the same functions. Thus, preferably there is no 
determine what operations are required to satisfy a change master/slave relationship among them. As also seen in FIG. 
password request. If the user were not logged on to the 10, user specific target configuration data and target pass- 
application, the LC would perform a logon operation and words (together, PKM data) of SSO users are stored in a 
then perform the change password operation. database 102, which may be DCE extended registry 

The flowchart of FIG. 9 is illustrative of the process. The 50 attributes (ERA) in the DCE Security Registry. When the 

routine begins at step 60 when the user desires to change a PKM server modifies data in the master registry, data 

password for his/her Target 1. At step 62, the routine gets consistency between the master and slave registries is 

Target 1 information from the PKM; here, the target type is achieved automatically by the data duplication mechanism 

Appl. The routine then gets the corresponding program of in registries. However, no encryption facilities are usually 

the given type from the CIM at step 64. A test is then 55 provided by the registry for data stored in ERAs. To avoid 

performed at step 66 to determine whether the user has to be target passwords being revealed to DCE administrators (or 

logged on to change his/her password. If not, the routine others), the password field is preferably encrypted with a 

continues at step 68 and the user password is changed. If, master key managed by the PKM server, before the whole 

however, the outcome of the test at step 66 is positive, a test target is stored in the database. Further, because multiple sso 

is performed at step 70 to determine whether the user is 60 servers can be configured for load balancing, a local copy of 

logged on. If the outcome of the test at step 70 is positive, this master key preferably exists in each one of sso servers, 

the routine branches to step 68; otherwise, the user is first The master key thus is generated automatically by one 

logged on at step 72. This completes the processing. server machine and "pulled" as needed by other servers 

A combination of the data model described and the LC when they are up and running. A simple "group" mechanism 

implementation thus provides "free seating" support. Free 65 provided by DCE (or some other similar mechanism 

seating means that the user does not have to specify a depending on the architecture implementation) is used to tell 

particular program on the client, or have a particular oper- which servers possess the valid master key. 
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The PKM data model elements were described above. The 
groups include: target name, target attributes, key 
information, user configuration and target class. The target 
name is the identifier used to distinguish a target from other 
targets. The target attributes include target type, domain/ 
host/application names and target user name. The key infor- 
mation contains the password of the user for the target and 
the type of the key derived from the password (e.g., a public 
key, a secret key, or the like). The user configuration is the 
user's own configuration preference when the user logons to 
and logoffs from the target. The target class defines whether 
the target is a password-based target or a passticket-based 
target. If it is a passticket-based target, a passticket-protected 
(e.g., RACF) application server's name must usually be 
specified. The above -described generalized data model 
enables all kinds of targets to be defined through the PKM 
API. Thus, in certain circumstances, not all the fields/ 
attributes may have values for each target because only a 
subset of attributes may be sufficient or meaningful for 
defining a specific, real target. In addition, because a pas- 
sticket for a protected server is dynamically-generated on 
demand, no password is required to be stored with a 
passticket-based target. 

PKM is preferably implemented as a client/server appli- 
cation in a distributed computing environment (e.g., Open 
Group DCE) as described above. The PKM server prefer- 
ably implements all PKM functions. In this illustrative DCE 
implementation, all target data is stored in DCE registry's 
ERA and the server accesses the data on behalf of each user 
on a client machine. Therefore, the PKM API is mapped to 
a set of remote procedure calls (RPCs) on each client 
machine using the DCE RPC mechanism. RPCs with dif- 
ferent protection levels (e.g., privacy or integrity) and dif- 
ferent properties are employed to pass data, depending on 
the API's security and semantic requirements. When the 
server receives a client's request, a thread is created to 
access the data in the ERA. If the request is a create, update, 
or delete operation, a write to the master registry is required. 
If the request is a query operation, a read from any slave 
registry is sufficient to carry out the operation. If a password- 
based target is queried, the password is retrieved from the 
ERA. Continuing with this DCE example, if a passticket- 
based ticket is queried, one more RPC is used to retrieve the 
secret key shared between the PKM server and the passticket 
server. The server then generates the passticket based on the 
secret key and other information configured for the target. 

One of ordinary skill will appreciate that the above PKM 
functions may also be implemented in other distributed 
environments besides Open Group DCE. Thus, the illustra- 
tive embodiment should not be construed to limit the present 
invention. 

Summarizing, the SSO approach described above pro- 
vides several advantages. The framework-based SSO 
mechanism enables all kinds of targets to be defined for any 
user. Different PKM implementations can be pluggable 
using the generic API without any changes to the programs 
using the PKM service. The described implementation (e.g., 
within a DCE architecture) makes user authentication, 
secure communication and data management much easier. 

The program template file (PTF) as previously described 
is a convenient mechanism for telling SSO how to interact 
with a given application or sub-system to perform SSO- 
related operations. The key benefit of the PTF is that it 
enables applications to be plugged into SSO without chang- 
ing the SSO code itself and without requiring any programs 
to be written to plug into the new application. 

As described above, the PTF file preferably contains the 
following relevant information: 
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Program name identifies the program/application being inte- 
grated. 

Target type specifies the type of target the PTF describes. 
The target type is used by other parts of SSO to specify 
an application of this type. 

Methods describes how SSO should perform SSO opera- 
tions. A stanza for each method exists which describes 
how SSO should perform the particular operation for that 
method. An example of the LOGON method for the LAN 
Server Application follows (see FIG. 8): 

[LOGON] 
capability =CLI 

interface-LOGON $U $P /D:$D 
rc_success=0 

rc_error=2100-2900,301Q-3240 
In this example, the method SSO would use to logon to LAN 
Server is specified by the capability (CLI for command line 
interface, API for application programming interface). The 
actual command to be executed is specified in the interface. 
The symbols $U, $P and $D represent username, password 
and domain, respectively. It is expected that SSO will 
replace those symbols with the username, password and 
domain the user is trying to logon to, as indicated in FIG. 8. 
Return codes from the interface are associated with buckets 
(rc_success, rc_error, etc.), allowing the appropriate action 
to be taken based on into which bucket the return code falls. 

Other methods preferably include START, LOGOFF, and 
CHANGE__PASSWORD. Additionally, the PTF describes 
additional application behavior such as whether the appli- 
cation needs to be started prior to logon, whether the 
LOGON method must be invoked before the CHANGE_ 
PASSWORD method, location information where the appli- 
cation exists on the physical machine, and method retry and 
timeout values. 

The following is a representative PTF: 
[MAIN] 

default_program_name (required): must be enclosed in 
quotes. SSO uses this as the default for program name in 
the Add Program user interface. 

default_program_name="example" 

format_version (required): should not be changed. SSO 
uses it to determine which version of SSO you used to 
create this program template. If you need to specify your 
own versions, use comments to do so. 

format_version =1.0 

targe t_type (required): is case sensitive. target_type must 
match the [TARGET_TYPE] defined in a file called a 
schema file. Use a predefined SSO target type or create a 
new one. To create a new one, specify it with no spaces 
and no quotes to guarantee uniqueness: 

type@DNS-name 

target_type- 

[SETTINGS] 

logon__sequence (required): defines the sequence in which 
the program expects start and logon operations to occur. 
Valid values are: 

prompt: The program preferably requires the start and logon 
to be performed in the same operation. The START 
section is ignored. The LOGON section is required. 

start_required: The program preferably is started before 
logon can occur. Both START and LOGON sections are 
usually required. 

no_start_required: The program can be logged on without 
being started first and can be started without subsequently 
logging on. Both START and LOGON sections are 
optional. 

logon__sequence- 
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change_password_sequence: typically required, defines 
the sequence in which the program expects the logon and 
change password operations to occur. Valid values are: 

logon_required: The program requires a logon before the 
password can be changed. Be aware of the following: 
If the target is not logged on and change__password_ 

sequence=Logon_required, the 

LOGON_AND_CHANGE_PASSWORD interface string 
is used to log on to the target and change the password. 
If the target is not logged on but change_password„ 

sequence is set to Logon_required, the LOGON interface 

string is used to log on to the target, and then the 

CHANGE_PASSWORD interface string is used to change 

the password. 

If the target is already logged on, the 

CHANG E_PASS WORD 

interface string is used to change the password. 

no__logon_required: The program allows a password to be 
changed whether the user is logged on or not. The 
CHANGE_PASSWORD interface string is used to 
change the password. 

change_password sequence = 

You should define either minimum_timeout or raaximum_ 
timeout. They both default to 0, which implies an infinite 
wait. If you define both, define minimum__timeout to be 
less than maximum timeout. 

minimum_timeout is the minimum amount of time, in 
seconds, that SSO should wait for a function to complete 
before returning. 

minimum_timeout applies to command line interfaces only. 
It is intended to be used for targets that return successfully 
right away but require initialization time before a subse- 
quent operation, such as LOGON, can be performed. 

maximum_timeout is the maximum amount of time, in 
seconds, that SSO should wait for a function to complete 

before returning, maximum timeout applies to both API 

and command line interfaces. It is intended to prevent a 
hang situation when a running process does not return 
when expected. 

minimum__timeout= 

maximum_timeout= 

directory (optional): defines the directory containing the files 
specified in the interface string definitions. In most cases, 
this is the default installation directory. If you do not 
specify a default directory here, you should specify the 
fully -qualified file names in the interface string defini- 
tions, 
directory- 
retries (optional): defines the number of times to retry an 
operation before returning an error. Retries are attempted, 
for example, when a return code defined in the rc_error 
return code bucket is received, 
retries- 

The Interface Sections 

Interface sections define the interfaces SSO will use to 
invoke your program to access the particular target type 
defined in the [SETTINGS] section. In general, the inter- 
faces define either an API call or a command line interface 
and the parameters expected. You can use substitution 
variables in the parameters to represent target- and program- 
specific information needed to invoke the function. 
Substitution Variables 

Substitution variables are reserved variables for target- 
specific information. The following substitution variables 
are commonly used for all target types: 
$U The target userid. 
$P The target password. 
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$N A user's new target password. SSO uses this value only 
in the CHANGE_PASSWORD and LOGON_AND_ 
CHANGE_PASSWORD interfaces. 
The following substitution variables preferably are used 
5 in some combination to identify the target system. Their 
exact meaning is defined in the schema file for the particular 
target type supported: 
$AThe target application name. 
$D The target domain name. 
io $H The target host name. 

$M, a reserved substitution variable, is a special message 
output parameter that lets you specify a text message that 
can be returned by the interface. SSO will write this 
message to the SSO log. This parameter may be used to 
is develop wrapper code to improve the integration of a 
given program with SSO. It may be used to give the user 
information should the interface not complete success- 
fully when invoked by SSO. 
Unreserved Program-Unique Variables 
20 Preferably, there are seven other substitution variables — 
$1 through $7 — that allow one to specify other program- 
specific information. If any of these variables are used, a 
section in the program template file may be included to 
define them. 

25 The capability keyword describes the type of program- 
ming interface required to start the program supported by 
this program template. Valid values are: 
API16 for 16-bit APIs. 
API32 for 32-bit APIs. 

30 CLI for command line. 

For example, capability=API32 

The interface string defines how to invoke the API or 
command line interface for this function. 
Specifying an API Interface 
35 interfaced <path-filename combo>function_return_type 

function_name(parml, parm2, . . . )" 

Specify the interface string, which preferably cannot be 
longer than 1024 characters, on one line. There are prefer- 
ably no continuation characters. Enclose the string in double 
40 quotes. Enclose the entire executable path and file name 
combination (path-filename combo) in less than (<) and 
greater than (>) symbols. The interface is _System linkage. 

Here is a representative description of the interface 
parameters: 

45 function_return_type«int, uint, long, or ulong 

fiinction_name is the API entry point. 

parml, parm2, and so on are parameters specified as: 

[parm_direction] parm_type parm_value 

[parm_direction]«[in] [out,max_is(size)] 
50 size is the number of bytes required to hold the output data 

from the function, such as $M in the example that follows. 

parm_type-int, int*, uint, uint*, short*, ushort*, long, 
long*, ulong, ulong*, char*, or uchar* 

parm_value -value 
55 value is either a "value containing spaces enclosed in 

double quotes" or a substitution variable. 

API Interface Example 

capability-API32 

interface-" <c:\appl\logon__ops.dll>int appLogon([in]char* 
60 stringval, [in]ushort $2, [in]char* $D, [out,max_Js(512] 
char* $M)" 
Specifying a Command Line Interface 
capability-CLI 

interface-"<path-filename combo>parml_value parm2„ 
65 value ..." 

Enclose the entire interface string in double quotes. 
Enclose the entire executable path and file name combina- 
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tion (path-filename combo) in the less than (<) and greater 

than (>) symbols. 

parml_value=value 

parm2_value=value 

value is either a "value containing spaces enclosed in 
double quotes" or a substitution variable. 
CLI Interface Example 
capability=CLI 

interface ="<c:\ibmlan\netprog net2.exe>$3" 
Return Codes 

Identify the category into which the return codes fall. 
Specify return codes as: 
A list of return codes separated by commas 
A range of return code values 
A combination of both 

rc_success: The operation performed on the target was 
successful. 

rc__information: The operation performed on the target was 
successful and the target returns information in the form 
of a null-terminated character string. SSO logs this char- 
acter string in the default error log. 

rc__chgpwd„error: A change password operation is neces- 
sary. SSO notifies the user. 

rc__credentials_expired: The user's credentials to the target 
have expired. Certain types of targets have time limited 
credentials. If the credentials have expired, the user might 
have to reissue a logon to that target. 

rc_error: The operation performed on the target produced an 
error, but the operation is worth retrying. SSO retries the 
operation until it reaches the maximum number of retries 
specified when the program was added. SSO displays 
status messages to the user while it retries the operation 
and at the point when it reaches the maximum limit of 
specified retries. 

rc_severe_error: The operation performed on the target 
produced an error so severe that there is no recovery. SSO 
does not retry the operation. 

[START] 

[START] defines the interface to start the program, 
capability* 
interface = 
rc_success= 
rc_information- 
rc_chgpwd__error- 
rc__credentials_expired= 
rc_error- 
rc_severe_error= 
[LOGON] 

[LOGON] defines the interface to log on to the target, 
capability- 
interface - 
rc_success- 
rc_information- 
rc__chgpwd_error- 
rc_credenlials_expired- 
rc_error- 
rc_jsevere_e rror- 
[CHANGE_PASSWORD] 

[CHANG E_PASSWORD] defines the interface to 
change the user's target password, 
capability- 
interface - 
rc_success- 
rc__information- 
rc_chgpwd_error- 
rc_credentials„expired- 
rc_error- 
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rc_severe_erroro 

[LOGON_AND_CHANGE_PASSWORD] 

[LOGON_^ND_CHANGE__PASSWORD] defines the 

interface to log on to the target and change the user's 
5 password. 

capability^ 

interface** 

rc__success= 

rc_information= 
to rc„chgpwd_error« 

rc„credentials_expired= 

rc_error« 

rc_seve re_error= 

[LOGOFF„FORCE] 
15 [LOGOFF_FORCE] defines the interface to force log- 
ging off of the target. 

capability" 

interface- 

rc_success= 
20 rc_information= 

rc_chgpwd__error= 

rc_credentials_expired= 

rc__error= 

rc__severe__error= 
25 [LOGOFF_GRACEFUL] 

[LOGOFF_GRACEFUL] defines the interface to log off 

gracefully (without loss of data) from the target. 

capability* 

interface** 
30 rc_success= 

rc_information= 

chgpwd_error= 

rc_credentials_expired= 

rc_error= 
35 rc_severe_error= 

Substitution Variables 

Use the unreserved substitution variables, $1 through $7, 

in the interface sections to represent program-specific infor- 
mation. Then, include a section, [$1], [$2], on so on, to 
40 define each one used. 

[$i] 

value-how is this specified? 
label-"text label" or ??? 
help-"text string" or ??? 
45 Define a value for each substitution variable using the 
value keyword. By using substitution variables, you sim- 
plify your interface sections. 

One can use substitution variables for information needed 
from the user. In this case, omit the value keyword or use it 
50 to specify a default value. Then, define values for the label 
and help keywords. SSO uses these to build a user interface 
(entry fields) for collecting the information from the user. 

SSO stores the value of the substitution variables, either 
specified or collected from the user, in the program infor- 
55 mation database on the client machine. 

Summarizing, single sign-on is facilitated by storing all 
the passwords and keys belonging to a user in secure storage 
(either in local storage, a centralized password service, or in 
a smartcard), so that the user needs to remember only one ID 
60 and password. The single sign-on ID and password is then 
used to authenticate the user. Upon authentication, the 
mechanism securely retrieves all the passwords for a user 
from the secure storage and automatically (without any 
additional user intervention) issues sign-ons to each appli- 
es cation the user is authorized to access. 

The present invention provides a framework that allows 
the PKM and the CIM implementations to be separable from 
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the rest of the single sign-on code. The functions provided 
by the aforementioned components are preferably imple- 
mented via a high-level API. Thus, a new implementation 
(such as Lotus Notes) can be added without causing a major 
redesign. This mechanism provides a logon coordination 5 
framework so that each specific target can be easily plugged 
into the single sign-on logon coordinator framework. This 
facilitates the support of the vast range of client server 
targets. 

The present invention enables efficient access to hetero- 
geneous networks at reduced costs to thereby increase 
productivity for end -users and system administrators. These 
advantages are achieved by enabling users to sign-on once 
with a single ID and password to access business applica- 
tions and data. The design goals achieved are ease of use, 
secure authentication of users, and logon coordination to 15 
multiple applications. 

The present invention provides numerous other advan- 
tages. It is based on an easy to use interface, and provides a 
consistent look and feel across operating systems. The tool 
is also advantageous in that it integrates with operating 20 
system logons, is based on open standards, supports "one 
time" passwords, and is capable of leveraging existing 
security infrastructures. 

One of the preferred implementations of the various 
modules described is as a set of instructions in a code 25 
module resident in the random access memory of a com- 
puter. Some of the framework functionality is supported in 
a client machine, and some of the framework functionality 
is supported in one or more servers. Until required by the 
computer, the set of instructions may be stored in another 3Q 
computer memory, for example, in a hard disk drive, or in 
a removable memory such as an optical disk (for eventual 
use in a CD ROM) or floppy disk (for eventual use in a 
floppy disk drive), or even downloaded via the Internet. 

In addition, although the various methods described are 
conveniently implemented in a general purpose computer 35 
selectively activated or reconfigured by software, one of 
ordinary skill in the art would also recognize that such 
methods may be carried out in hardware, in firmware, or in 
more specialized apparatus constructed to perform the 
required method steps. 40 

Further, although the invention has been described in 
terms of a preferred embodiment in a specific network 
environment, those skilled in the art will recognize that the 
invention can be practiced, with modification, in other and 
different network architectures with the spirit and scope of 45 
the appended claims. Moreover, the logon coordinator may 
be useful in other than single sign-on (SSO) environments. 

Having thus described our invention, what we claim as 
new and desire to secure by Letters Patent is set forth in the 
following claims. 50 

What is claimed is: 

1. A method of single sign-on to multiple target resources 
in a computer enterprise environment, wherein at least some 
target resources normally require a given logon process to 
access the target resource, comprising the steps of: 5S 
for each of a set of target resources having different 
respective logon processes, storing configuration direc- 
tives each of which include a target type and informa- 
tion identifying the given logon process and methods 
required to access the target resource; 60 
during a logon attempt by a given user with respect to one 
of the set of target resources, determining whether any 
of the configuration directives include a given target 
type; and 

if any of the configuration directives include the given 65 
target type, using information in the configuration 
directive to access the target resource. 
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2. The method as described in claim 1 wherein the 
configuration directives are stored in a database at a client 
machine from which the logon attempt is initiated. 

3. The method as described in claim 1 wherein the at least 
one configuration directive is generated from a user- 
specified logon preference. 

4. The method as described in claim 1 further including 
the step of modifying at least one configuration directive in 
the database. 

5. The method as described in claim 1 wherein during the 
logon attempt, given user information is coordinated with 
the configuration directives. 

6. The method as described in claim 5 wherein the given 
user information is user-specific and application-specific 
information that enables a given user to access and logon to 
one or more target resources. 

7. The method as described in claim 6 wherein the given 
user information is stored in a globally-accessible database, 

8. The method as described in claim 1 wherein the 
configuration directive is defined by a template file. 

9. A system for enabling access to a target application on 
a target resource in a distributed computer enterprise, com- 
prising: 

a database for storing configuration directives each of 
which include a target type and information identifying 
a given logon process and any associated methods 
required to access a target application on a target 
resource; 

means operative during a logon attempt for determining 

whether any of the configuration directives include a 

given target type; and 
means responsive to the determining means for using 

information in a given configuration directive to access 

the target resource. 

10. The system as described in claim 9 wherein the storing 
means is a database located at a client machine from which 
the logon attempt is initiated. 

11. The system as described in claim 9 wherein at least 
one configuration directive is generated from a user- 
specified logon preference. 

12. The system as described in claim 9 further including 
means operative during the logon attempt for coordinating 
given user information with the configuration directives. 

13. The system as described in claim 12 wherein the given 
user information is user-specific and application-specific 
information that enables a given user to access and logon to 
one or more target resources. 

14. The system as described in claim 12 wherein the given 
user information is stored in a globally -accessible database. 

15. The system as described in claim 9 wherein the 
configuration directive is defined by a template file. 

16. A computer program product in computer-readable 
media operable on a computer for enabling access to a target 
application on a target resource in a distributed computer 
enterprise, comprising: 

means for generating configuration directives each of 
which include a target type and information identifying 
a given logon process and any associated methods 
required to access a target application on a target 
resource; 

means operative during a logon attempt for determining 

whether any of the configuration directives include a 

given target type; and 
means responsive to the determining means for using 

information in a given configuration directive to access 

the target resource. 
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17. The computer program product as described in claim 
16 wherein the configuration directives are stored in a 
database of the computer. 

18. The computer program product as described in claim 
16 wherein at least one configuration directive is generated 
from a user-specified logon preference. 

19. The computer program product as described in claim 
16 further including means operative during the logon 
attempt for coordinating given user information with the 
configuration directives. 
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20. The computer program product as described in claim 

19 wherein the given user information is user-specific and 
application-specific information that enables a given user to 
access and logon to one or more target resources. 

21. The computer program product as described in claim 

20 wherein the given user information is stored in a globally- 
accessible database. 

***** 
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